The Rocinante Essays

Why Enterprise VR Failed - Episode 3: Development Tools? What Development Tools?

• Daniel Eckert • Season 1 • Episode 3

Share episode

Episode 3 of our series on "Why Enterprise VR Failed" pokes fun at the underbelly of VR software development tools to determine if software is the true villain of our story or was it wildly misaligned teams and a tech industry that promised a holodeck and delivered us Microsoft MESH? 

From the Unity vs. Unreal holy war to bloated dev teams that needed more roles than a James Cameron movie, it was clear we had entered Crazy Town. 

And just when IT finally got involved? Things got worse.

Welcome to Why Enterprise VR Failed, a seven-part audio essay produced by Rocinante Research, copyright 2025.

This is Episode 3: "Enterprise VR Development Tools? What Development Tools?"

These audio casts accompany the written series published on Linkedin and Medium, but are not a word-for-word reading. They are for those who’d rather be serenaded by a glitchy AI narrator than suffer through another 4,000-word white paper written by someone who uses “synergy” unironically. 

If listening to the retelling of headset-fueled heartbreak is your jam then continue on my friend as we crank up the snark and unpack how Enterprise VR swan-dived straight into the dumpster fire behind your IT department.

But, before we get started, I need to introduce some additional voices you'll hear throughout this audio cast. 

There's the Narrator's voice (that’s me), I'm here to guide you through the chaos, keep things moving, and make sure the sarcasm stays on-brand.

I'm the Author's voice and I will drop in with personal opinions and battle-worn stories from eight years in the enterprise VR trenches, bravely trying to keep a straight face as we listen in on what academia thinks is "state of the art."

The Client, that's me, I'll be voicing the project managers, executives, and the poor souls in the enterprise who had to live through this Metaverse acid trip.

And finally, this is the Vendor voice and I'm really here to just smile, agree, and then blame the consultants when none of it works.

Let's recap what has happened so far.

Episode 1 of this series focused on the value VR brought to the Enterprise. Episode 2 concentrated on the hardware companies like Meta, HTC, and Pico that built wireless VR headsets. Unfortunately, they launched Enterprise VR like a beta product with no patch notes - while early adopters freaked out because they couldn't get these overpriced consumer devices through provisioning. 

Enterprise VR was this close to being the next big thing. Consultants, L&D, and Marketing couldn’t shut up about how it would revolutionize training, collaboration, and simulation. The future was so bright, all you needed was an Apple Vision Pro to look at it.

And yet here we are in 2025 and Enterprise VR has pretty much crawled back into the supply closet. 

We have now arrived at Episode 3, where we will poke fun at the underbelly of VR software development tools to determine if software is the true villain in our story. 

Just like episode 2, this audio cast is divided into four scenes. 

Scene 1 will be a brief history lesson on Enterprise Development tools and technologies used to build internal applications. In other words, the decoder ring to understand the phrase, “Just because you could build webpages and mobile apps does not make you a VR developer.”

Scene 2 introduces the audience to the Unity verses Unreal debate. It looks at the two biggest players in VR software development tools. We’re diving into this rivalry not because we wanted to geek out on another tech holy war, but to understand what each brought to the VR table… and how that table promptly collapsed under the weight of expectations.

Scene 3 introduces the phrase, Wait, how many people are on your VR team? And How much is this application going to cost to build, test, deploy, and manage?

And finally Scene 4, The rise of no-code development platforms brought to you by the Duct Tape and Pray School. Because non-developers understand what it takes to build an enterprise application better than those neckbeards in IT.

Scene 1, A History Lesson on Enterprise Development Technologies:

Or, how we went from white lab coats to triple X L pizza-stained T-shirts—without somehow burning the whole place down.

Enterprise software development isn’t just a story — it’s an epic saga of human stubbornness, bad decisions, and heroic efforts to glue the future onto the past.

You can neatly categorize enterprise software development into eras, much like archaeologists do with ancient civilizations

Except instead of human burial remains and pottery shards, we’ve got Lotus Notes servers, Fortran, punch cards, and passive-aggressive Jira tickets. Oh, and that suspicious smell coming from the data center break room.

Each era had its own holy relics (technology), priesthoods (developers), and rituals (SDLC, Rad, Jad, and the ultimate square peg in round hole – Six Sigma). Each era also came with its own tech stack, quirks, and corporate trauma. 

Understanding these eras is key because IT developers tend to get trapped — skill-wise and emotionally — in whatever era they started their career in. So yes, it is possible to carbon-date a developer by just listening to the buzzwords they still use unironically.

Now, if you’ve never had the joy (or horror) of peeking behind the curtain of a large enterprise IT shop, brace yourself: it’s not so much a “department” as it is a migrating herd of complexity, stitched together by thirty years of “temporary” solutions that somehow became permanent. 

Calling it “organized chaos” would be generous — imagine a piñata filled with bees, placed on a trampoline, being struck repeatably by a stick built with Cobol.

And that’s just the software development side. If we added operations, support, architecture, project management, or product management to the discussion, we’d need to hire a grief counselor and maybe an exorcist.

As a consultant of more than 30 years, I can promise you entire industries have been built around helping companies survive their own IT departments.

In the posted article that is available online, there is a large table that summarizes each of the eras beginning with the mainframe era in the nineteen sixties and ending with the Generative AI and Data-Driven Era that began in twenty-twenty-two. 

Somewhere in the early twenty-tens the Mobile and API driven Era emerged as it was a direct response to the iPhone and mobile apps entering the enterprise. 

To save you from a deep analysis of this table that only a true techno-weenie would enjoy, we want to just highlight that VR software development begins occurring around the exit of the Mobile & API-Driven Era around 2016. This is where Enterprise VR tools like Unity and Unreal enter the picture.

This is important as the developers entering the workforce in and around 2016, were schooled in the arts of Mobile Application Development, API's, Java, .NET, C-Sharp, and HTML and, in general, would become the generation that built the first enterprise VR applications in the Oculus Era.

Scene 2: The Unity vs. Unreal debate

One of the most important decisions you need to make before developing enterprise VR applications is determining the target VR headset you want to use. The second critical decision is choosing a software development platform that enables you to build applications for said headset.

Back in 2016, there were only a handful of development options: Unity, Unreal Engine, 360VR or WebVR, and a few proprietary engines. Each came with a catch—once you picked a platform, switching later usually meant rewriting large chunks of code. You also had to make sure your chosen platform actually supported the target headset you selected, because cross-compatibility was far from guaranteed. As for proprietary engines, those were mostly reserved for defense contractors and high-end simulation work - and rarely used for wireless headsets that the enterprise preferred. 

For this audio essay, we’re focusing on the three major development platforms that shaped the Enterprise VR landscape. Each platform will be introduced by the vendor.

Unity started in Denmark, but its global headquarters are now in San Francisco. It’s not just a game engine; it’s a full-featured, cross-platform development powerhouse and is widely used for creating mobile applications. Whether you’re building mobile apps, VR training simulations, or interactive enterprise experiences, Unity gives you the flexibility and performance to bring it all to life.

Unity uses C sharp for scripting and provides a rich asset store, physics engine, and rendering tools to streamline VR development. Unity is licensed by developer seat and keeps licensing simple because they only charge for the developers that create applications, not for the people that use the applications.

Unreal Engine is owned by Epic Games, one of the largest game publishers in the world. If you’re looking for jaw-dropping visuals and industry-leading performance, look no further than Unreal Engine. After all, it powers just about every triple A computer game ever developed —and for good reason.

Unreal Engine is based on C plus plus for development and is licensed using a revenue sharing model—typically 5% of total sales. That approach makes sense for commercial game developers selling millions of copies. But here’s the rub for enterprises: if your app is internal or non-revenue-generating, what exactly are you paying 5% of? That’s where things get fuzzy, and why Unreal hasn’t always played nicely in traditional enterprise settings.

Looking for an easy way to deliver immersive VR experiences without hiring a full dev team? That’s where 360VR and WebXR platforms come in. These tools are perfect for creating 360-degree virtual environments—ideal for procedural training, virtual tours, onboarding, or any experience where you want your audience to look around as if they are really there. 

Most of these platforms are no-code, which means you can build compelling, interactive content without writing a single line of code. It’s fast, scalable, and incredibly effective—especially in industries where time and budget are tight.

Licensing for these platforms comes in many flavors, but one of the more successful approaches is by usage. When a user launches a no-code created application, the user's company is charged a small license fee (typically under $5). These no-code platforms often serve as a steppingstone for companies new to VR, offering an accessible entry point but with limited interactivity and scalability.

Sure, there were other ways to build VR apps—but most enterprises just handed the whole thing off to consultants or creative agencies.

You see, convincing IT to retool a backend dev to build a one-off VR proof-of-concept was like asking your dad to install TikTok—confusing, mildly dangerous, and ending in a shouting match about why he needs a brand deal to support his “Back-in-my-Day” coaching business.

And let’s not forget: VR made marketing departments giddy. It was shiny, it moved, and it looked great on a tradeshow reel, so they were more than happy to skip the IT gauntlet and throw it over to their favorite flashy ad agency. Farming it out was faster, prettier, and didn’t involve begging IT for server access.

It’s important to note that consulting companies tended to gravitate towards Unity (similar coding tools and licensing model to traditional IT efforts) and Creative houses gravitated towards Unreal Engine (because you know... Pretty!).

What determined the development platform? There's actually a really easy answer: whatever the dev team already knew.

If they cut their teeth on mobile apps or .NET, they spoke fluent C sharp and naturally gravitated toward Unity. If they had a background in game engines—or just liked rendering bananas in ultra-HD—Unreal was home. In the world of Enterprise VR - Unity was far more common for a majority of builds because the dev team had experience with the core technology (C sharp) and the license model was more predictable.

In nearly every case, the enterprise ended up footing the bill to upskill third-party vendors on these shiny new tools. Why? Because very few people had ever actually built a VR app before. And if you were building a simulation? Forget a quick 6-week turn and burn—you were staring down man-years of work. By 2019, the average VR project took 12 -18 months and cost somewhere between $500K and $2M. (Yes, cheaper options like 360VR existed, but we’ll get to the bargain bin later.)

And because everything was so new, Unity and Unreal didn’t exactly play nice. You couldn’t just build in Unreal and then switch to Unity (or vice versa). Choosing a platform meant locking yourself in. If you changed your mind? You were basically starting from scratch.

So naturally, each enterprise picked a single platform, standardized their toolset, and created a consistent experience across all VR apps… right?

Of course not.The business made decisions based on budgets, buzzwords, or which vendor had the flashiest pitch deck, the lowest cost, and most attractive sales rep. The result? If you built three apps, they were probably developed three different ways by three different vendors—with completely unrelated user experiences.

Using these apps back-to-back felt like jumping between a flight simulator, a cooking show, and “Asteroids”.

Eventually, IT caught wind of the chaos and said, “You know what? We should build this in-house and do it right.”

And then…everything got worse.

Scene 3: Wait, how many people are on your VR team?

You have a few VR prototypes under your belt and leadership is very excited at what they have seen and want to see more. Your boss is putting pressure on you to stop outsourcing development and asks you "what it would take to bring VR development in house." Excited, you put together a list of what you need:

Here's a list of the roles and skills necessary to build a VR application. For our discussion, let's just call it the Enterprise VR Development Dream Team:

The Production Lead: The person in charge of herding the cats, holding the budget hostage, and pretending everything is on schedule, even if it is not.

A Project Manager: Lives in spreadsheets, breathes Gantt charts, and exists solely to ask, “Can we get an update on that?” every 14 minutes.

The Learning Lead: Makes sure this isn’t just “cool tech” but also, you know… actually teaches someone something.

A Creative Lead: Wears glasses with no lenses, says things like “aesthetic narrative arc,” and fights everyone over color palettes.

The Technical/Development Lead: Writes 100 lines of code and 300 lines of Slack messages explaining why the last update broke everything.

The Interactive Learning Lead: Translates corporate training into VR magic—turns “don’t touch that” into a virtual fireball experience.

A Script Writer: Crafts dialogue for training avatars that somehow need to be professional, relatable, and not sound like a lawyer.

A Story Board Designer: Draws glorified comic books to help executives pretend they understand what this project is about.

The Game Engine & Platform Developer: The sorcerer behind the curtain who makes the headset do things, occasionally sacrificing a weekend (and a goat or two to the Unity community).

The 3D Modeling & Asset Creator: Builds realistic office chairs, plants, forklifts, and brings awkward avatars to life in glorious low-polly detail.

The Animation & Motion Capture Creator: Wants to mocap everything—including the intern sneezing—because, you know “authenticity.”

The Physics & Interaction Designer: Makes sure things don’t float, fall through floors, or accidentally slap you in the face with virtual objects while moving from Point A to Point B.

The Audio & Spatial Sound Designer: Makes a PowerPoint about the emotional arc of a door creak. Wears headphones all the time and silently judges you.

The user experience engineer: Screams into the void when Creative Lead says “just make it intuitive” for the 12th time.

The Production Artist: The last-minute miracle worker who fixes every asset, graphic, and UI element even though everyone else has already signed off on the previous assets.

And finally, the Deployment, Testing & Performance Optimization Engineer. The person responsible for making sure the app doesn’t melt the headset, run out of battery after about 20 minutes, or crash when some mid-level executive finally puts it on their head so they can snap a picture for Linkedin to promote how "they" experience the future. 

16 different roles. 16 different personalities. 16 different egos. 16 different skillsets. In hindsight, it wasn’t a project team —it was a casting call for a reality show that would eventually end up on the Discovery Network.

With excitement, you begin to put together your budget and staffing request. As you go through it you begin to realize that unless you are building 3+ VR experiences in parallel, many of these roles are not needed 100% of the time so it may be necessary to find people that can wear multiple hats, or just backfill specific spots with a contractor. 

You've determined it's time to reach out to IT to help understand what you’ll need and maybe over to marketing where the creative people are hiding.

Stated eloquently by an Immersive Experiences Lead at a Fortune 500 Company: “What I discovered is that many of these skills are not normally found in an enterprise. Our team was a collection of contractors, creatives, trainers, developers, and executives. The biggest problem I had creating and deploying these types of solutions, well, it involved having people that didn’t normally work together, you know, work together.”

The next thing you know is your boss called you into their office – and HR has joined him. Oh crap. Time to get on your bicycle and start pedaling.

The first question they always asked, “What happened and what went wrong?"

Well, everything. Underestimating the time it took, realizing that legal and/or HR needed to be involved in everything to do with the script. We needed to create learning objectives that were far beyond what we normally had to define, and tie them to outcomes. We completely underestimated the budget. Managing scope was even harder than managing the different personalities and egos. Delivering a solution that resembles the initial vision just didn't seem possible. 

You can sense the frustration in this VR Project Leader's comments as they continued. Did you know it took six months just to finalize the voice-over script? Most of that time was spent trying to convince HR and Legal that no one—and I mean no one—says things like, “Please ensure you have reviewed the relevant compliance documentation prior to engaging with the steering controller.” This was supposed to be a conversation between two forklift drivers, not a courtroom deposition. People don’t talk like that. Ever.

We ended up seven figures and eight months over budget, mostly because we had to navigate approval purgatory for problems we didn’t even know existed until this project.”

Rarely, in more than 8-years building interactive solutions for clients had I run across a single company that built their own interactive solutions in-house more than once or twice. They looked at the bills, the timelines, the interdepartmental trauma—they just noped out. Building your own sounded cool but ended many a career.

The exception? Companies that went down the 360VR route and discovered no-code solutions. And defense contractors who don't really think about budget unless you are exceeding $50M for the project (and those that think $1M is a rounding error).

Scene 4: The rise of no-code development platforms

No-code VR development platforms let you build virtual reality experiences without touching a single line of code. With visual interfaces, drag-and-drop tools, templates, and built-in logic, they empower non-developers—like designers, educators, and subject matter experts—to create immersive content for training, education, and storytelling.

It’s like building Ikea furniture… if Ikea made forklifts.

During COVID, we trained a dozen graphic designers with no VR or coding background, and asked them to build a VR app that taught technicians how to correctly clean a pool filter. Two weeks later, we had an 8-year-old take the training, and then successfully clean a real pool filter. Two weeks from zero to hero. I can’t even get a refund from NewEgg in two weeks. - Shared by a VR Program Lead from a Big 4 Consulting Firm. This was just one example of the many no code success stories.

No-Code VR Development Tools had many advantages including:
Enabling fast prototyping that let non-developers build and iterate quickly without needing a coding god or requiring deep them to possess deep technical skills.

They were lower cost in comparison to traditional development tools because they reduced reliance on expensive engineering teams.

They were very accessible to more people. These platforms empowered trainers, educators, and designers to directly create their content without having to translate their ideas for a developer to code.

These platforms also provided prebuilt components - Often including templates for menus, environments, and interactions to help creators reach their desired outcome quickly.

And they supported cross-platform deployment - Some tools allowed exporting to application to the web, mobile phone, and multiple VR headsets with minimal setup. 

They were the poster child for create once - deploy everywhere!

But, these no-code platforms also had some disadvantages. 

They had limited customization capabilities - In other words they were difficult or impossible to implement advanced features, or create custom logic that wasn't supported by the platform.

They had Performance Bottlenecks - and for a long time were not optimized for complex enterprise-scale VR applications. 

They provided limited Source Code Access as it was not easy to modify the underlying engine or integrate a custom SDK easily.

It was really hard to build training that required fine hand motor skills - in general, they really couldn't do it. 

And finally, they did not support large-scale multiplayer simulations.

No-Code solutions shine in industries where there is high turnover, or you need to teach an unskilled worker to perform simple physical tasks. VR training is a lot more exciting than sitting through an e-learn, and, as a bonus, trainees don’t start anything on fire. There are a few companies that have built over 400 training experiences entirely in-house using no-code platforms.

Conclusion

It's now time to ask the key question of episode 3. Did Software Kill Enterprise VR?

The enterprise software development landscape was already a hot mess of tech debt, tool sprawl, and skill silos. Then. someone tossed in VR—an exotic new ingredient with zero recipe cards.

No standard platforms. No reusable assets. No playbook.The tools were fragmented, the platforms incompatible, and the skillsets required looked like a requirements doc for the next Avatar movie.

And yet… for all the burned budgets and abandoned headsets, there was a spark.

Somewhere in the ruins, the no-code tools and Unity or Unreal prototypes showed us that maybe—just maybe—this could work for the right problems, with the right people, using the right expectations. A simple 360VR training didn’t need 16 roles and a mocap rig. It needed someone who knew the job and someone who could drag-and-drop with a bit of style. 

No-Code solutions didn't enable you to build complex simulations, or collaboration experiences, or some of the more comprehensive types of training scenarios, but it did help keep the foot in the door.

In the end, building VR software at scale was like throwing a surprise birthday party in a minefield: expensive, confusing, and liable to end your career if you stepped in the wrong place.

So, was software the villain in this story? Not completely. Let’s call it an accomplice. Along with unclear business goals, undercooked budgets, wildly misaligned teams, and a tech industry that promised us a holodeck and delivered us Microsoft mesh.

Say, what ever happened to all those executives who pushed seven-figure VR projects? Oh, they’re leading AI strategy now. Naturally.

Let me summarize: Software probably wasn’t the villain, but it was definitely driving the getaway car.

We’ve identified both Hardware and Software as contributing factors to the failure of Enterprise VR. But they are not the only culprits. Up next in “Episode 4: The IT Problem, or How the middle finger can be used as a pointing device” we dive deeper into the maelstrom of dealing with IT to deploy VR solutions in the enterprise.

About the Author

Daniel Eckert retired from 29-years of consulting in late 2023 after spending 8-years on the front lines of Enterprise VR, preventing big companies from overhyping, under-investing, or half-baking VR solutions. He also co-authored the landmark paper The Effectiveness of Virtual Reality Soft Skills Training in the Enterprise — a paper cited half as often as any VR pitch deck containing the words “immersive synergy pipeline.” Daniel now spends his semi-retirement as a Principal at Rocinante Research. Check out some of his other articles on Medium.

If you liked this audio essay, smash that share button like you’re flailing through a Beat Saber solo on Expert+ after three espressos. Got thoughts? Cast them into the comments like a cursed spell — I accept praise, hot takes, unsolicited philosophical rants about Ready Player One, and your most unhinged theories about how an AVP is secretly Skynet in a ski mask. If you hated it, just shout “Spatial computing is just iPadOS for your face!” into your next VRChat session and remember it could be worse… you could be staring into the black mirror of a Meta Quest Pro wondering if you ever actually left that team-building simulation in 2019. (You didn’t. You’re still in there. The facilitator just never logged back in.)